In a typical network environment, multiple client computer systems (clients) are connected to one or more server computer systems (servers). In a first common arrangement, each client includes an operating system, and optionally other software, stored on a hard file within the client. On power-up or reboot, the client boots from the operating system stored on the hard file without reference to the server computer. This type of boot is called a local program load. Other application software e.g. word processing, database software etc, held on storage associated with the server system, is accessed as needed by the client.
In an alternative boot technique, the client does not boot from a locally stored operating system. One reason for this is that the client does not have a local mass storage device such as a hard file on which the operating system software can be stored. Such client systems are often referred to as `diskless` systems. Consequently, when a diskless client is powered-up, the client executes code within a read only memory (ROM) on the network card within the client which causes the server to transfer the operating system software to volatile storage in the client for use until the client system is powered-off.
There are currently two main methods used to boot a diskless client from a server over a local area network. The first of these is the Remote Initial Program Load protocol (hereinafter termed `RPL`), which is based on the IEEE 802.2 Data Link Control standard, and which is used primarily by Personal Computers (PCs) for example in Token-Ring Networks. The second method is the TCP/IP Bootstrap Protocol (BOOTP) which is used primarily, though not exclusively, by UNIX workstations.
Although the RPL and BOOTP methods make use of the same basic concept, they are in fact incompatible in that it is not possible to boot an RPL client from a BOOTP server or vice versa. With the growing use of TCP/IP on networks of PCs, a method of booting a PC over the network using TCP/IP is desirable. One solution to this problem would be to provide the PC customer with two separate bootstrap ROMs thereby allowing the customer to choose BOOTP or RPL depending on the type of network in which the PC is to be employed. However, if the customer wishes to change from BOOTP to RPL then it is necessary to change the ROM.
What is needed therefore is a technique allowing booting in a mixed network environment, for example to allow an RPL client to boot from a BOOTP server.